An Update on ANSI/NIST-ITL activities 



Workshops were held at NIST on October 30 and 31 concerning 

• Update of the Mobile ID Devoice Best Practice Recommendation (BPR) 

• A 2015 Update to the ANSI/NIST-ITL standard 

See http://www.nist.gov/itl/iad/ig/ansi kickoff 2015.cfm for summaries. I beUeve 
that the general sense of the participants was that both activities are worthwhile 
pursuing. It will be several months before we finalize the revised versions, so there 
will be lots of chances for you to provide input and to comment. 

I am going on international travel for a few weeks, so my next update to you will be 
in December. My first task will be to update the skeleton BPR that is on the website 
http://www.nist.gov/itl/iad/ig/mobileid.cfm with as much information as possible 
- based upon the discussions of the meeting on October 30. 

The ANSI/NIST-ITL 2015 update meeting results in the formation of a group to 
address fingerprint issues - chaired by Greg Cannon. Please contact him at 
Gregory.Cannon@crossmatch.com if you would Uke to participate. One major focus 
to be addressed is how to update Table 7 to handle multispectral, photo, contactless 
and other types of friction ridge acquisitions (based upon a presentation by Mike 
Garris). 

The group agreed to put several items into the 2015 draft, including: 

• A new code of Tonal Reversal Unknown in Field 9.314 

• Revision of Annex E on guidance about taking photos and the wearing 
of glasses 

• Addition of text to explicitly mention NFIQ2 and how to enter its 
values 

• A new format for Annex G (showing the fields, mnemonics and XML 
tags) - based upon Machine Readable Tables 

It was agreed that we need more discussion about: 

• Adding a new PAP code to specifically handle 3.2" x 2.0" platens 

• Indicating that codes 29 and 30 in Table 8 are obsolete (Palm - right 
other and left other) 

A major impetus for considering a 2015 Update was that NIEM has introduced a 
new version. What should the ANSI/NIST_ITL standard do to reflect this change and 
to handle future NIEM revisions as well? 

Background: 

1) The 2008, 2011, 2013 versions of the standard are based on NIEM 2.1 



2] ANSI/NIST-ITL has been committed to development of the NIEM 
Biometrics Domain -- since 2011. It is now fully reflective of the elements 
that are required by ANSI/NIST-ITL that are not contained in other 
namespaces such as: 

a. NIEM core 

b. The specialized FBI namespace for NCIC codes 

3) Implementations of ANSI/NIST-ITL using XIVIL are in existence and are 
based upon NIEM 2.1 

4) Manufacturers have hard-coded ANSI/NIST-ITL output based upon NIEM 
2.1 into certain products such as fingerprint capture systems and 
RapidDNA units. 

NIEM has been extremely successful in facilitating interoperability by specifying a 
common naming convention for data elements and specifying their associated 
attributes. ANSI/NIST-ITL recognized this in adopting NIEM for its XML 
implementation. In addition, many US agencies are required to use NIEM. 

Our challenge is to determine how to best use NIEM for a distributed, international 
environment, with several different vendors selling computer programs that 
generate ANSI/NIST-ITL transactions, and maintain interoperability. The standard 
has adopted the approach to its 'content' of adding new features in a structured 
approach that does not impact users choosing not to implement the new features. 
They simply won't send the new record types or fields that the standard technically 
allows. If a recipient gets a transaction with record types or fields that the receiver 
does not have implemented, they are simply ignored. 

This concept would have to change dramatically if we were to adopt updated 
versions of NIEM core. The conversion of NIEM from version 2.1 to version 3.0 
removed 75 elements from NIEM core. Unfortunately, this directly impacts 
ANSI/NIST-ITL encoding. In fact, the very element that we used to transmit 
biometric data was removed. A new element with a different name has been added 
to NIEM 3.0 to handle the same function. The same is true for basic metadata 
elements such as 'Year'. So, a 'translator' is needed to make transactions created 
under NIEM 2.1 readable for systems using NIEM 3.0 and vice-versa. This will 
become more compUcated when NIEM 4.0 is released in two years. Translations 
will be needed for all possible combinations of sender and receiver, and those 
translation packages would have to be installed ever5^here that could potentially 
receive a transaction from a place that relies upon a different version of NIEM core 
or sends a transaction to a site that does not have a translator installed - which is 
likely since places would not update simultaneously all around the world. I raised 
this issue at several recent NIEM meetings. 

NIEM has offered to develop such a translator, and we could post it on the 
ANSI/NIST-ITL website along with instructions on how to use it. Technically, this 
approach COULD work, IF every sending and receiving organization were to always 
know the NIEM version of their correspondence partner. Unfortunately, that may 



not be the case. For instance, if a disaster occurs, and fingerprints / photos/ dental 
and DNA information is sent from a pohce agency in country X to a morgue at the 
disaster site in country Y, they should be able to send the transactions without 
having to coordinate and adapt the computer code to accept the appropriate version 
of NIEM core. 

Thus, my recommendation is: 

• Keep all references to elements in NIEM core used in the ANSI/NIST- 
ITL schema at NIEM 2.1 version 

• Encourage vendors to build to the schema pubUshed on the 
ANSI/NIST-ITL website that uses NIEM 2.1 and not develop their own 
using later NIEM versions. 

• Continue to update the NIEM Biometrics Domain with new elements 
and attributes as needed by ANSI/NIST-ITL and the application 
profiles (such as EBTS) 

• Explicitly state in the standard that use of any NIEM core versions 
past NIEM 2.1 will cause interoperability problems and should be 
avoided UNLESS the exchanges are in a 'closed system' where all 
parties can update simultaneously. 

In this way, the standard will not have to be updated each time that NIEM changes 
and we would still be NIEM-conformant (an important consideration). We would 
also be able to take advantage of Biometrics Domain updates, which is also very 
advantageous to us as we add new capabilities to the standard. 

Please let me know what you think about this approach to handling NIEM revisions 
in the standard. 



